Fixes #62471

Description

This PR fixes a RangeError: Maximum call stack size exceeded crash in the TypeScript Server (VS Code Extension) that occurs when invoking "Refactor..." actions on code involving recursive generic types.

The issue was caused by symbolWalker entering an infinite loop when traversing recursive types (e.g., a type referencing itself in a property). While the walker already had cycle detection via visitedTypes and visitedSymbols, it lacked a depth limit. This allowed cases where the recursion depth exceeded the JavaScript call stack limit before the cycle detection could take effect.

Reproduction

The following code triggers the crash when trying to use "Refactor..." (e.g., Extract Function) on the selection:

type ProblematicType<T, D> = {
  prop: ProblematicType<T[keyof T], any>;
};

function func<T, D>(param: ProblematicType<T, D>) {}

class TestRefactoring<T> {
  method() {
    func<T, any>(null as any);
  }
}

Behavior:

• Before: TS Server crashes immediately with RangeError: Maximum call stack size exceeded.*

• After: Refactoring menu opens correctly (or shows "No refactoring available"), and no crash occurs.*

Implementation Details

I modified src/compiler/symbolWalker.ts to add recursion depth tracking in the visitType function.

Key Changes:

1. Depth Tracking: Introduced a level counter and a maxRecursionDepth constant (set to 100) to track the current recursion depth.
2. Early Termination: Added a check to return early if level > maxRecursionDepth, preventing the stack overflow.
3. Proper Cleanup: Wrapped the type visiting logic in a try-finally block to ensure the level counter is properly decremented even on early returns or errors.

Why this approach (Defense-in-Depth)?
This works in conjunction with the existing cycle detection (visitedTypes) to provide a robust safeguard:

• The visitedTypes array prevents infinite loops on direct cycles.
• The new depth limit prevents stack overflow on deeply nested recursive structures that might blow the stack before completing a full cycle.

Test Plan

1. New Test Case: Added a new fourslash test case tests/cases/fourslash/extractFunctionSymbolWalkerInfiniteLoop.ts.

• This test reproduces the crash scenario by invoking verify.not.refactorAvailable("Extract function") on the recursive type pattern shown above.
• The test verifies that the refactoring is correctly unavailable (or available without crashing) for this edge case.
• The test now passes without causing a stack overflow.

2. Regression Testing:

• Ran existing tests to ensure no regressions in other refactoring features.
• Successfully ran hereby runtests locally.

Baseline Changes

• None: This change only fixes the crash logic and does not alter emitted output or existing error messages. The change is purely defensive and only affects the internal traversal mechanism of the symbolWalker.